The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Developing a user interface for a Java®-based computer application for use by an HTML browser typically involves several tasks. In general, for each user operation that can be performed in the user interface, a JSP page is created to collect user data; JavaScript is created to perform client-side data validation, such as verifying that a valid date value is entered in a date field; and Java code in the form of servlets or action classes is written to process the user data. Programmers and software developers can use several existing tools to facilitate each of the above steps. For example, Macromedia Dream Weaver supports JSP page layout, design, and in developing JavaScript code. Tools such as Visual Café or Borland JBuilder are used for developing Java code.
However, certain complex computer applications, such as network management systems, may support hundreds of different user operations, which require development of several hundreds of JSP pages and Java classes. The large number of JSP pages and Java code linked with the JSP pages not only increases development time, but also poses a serious problem in managing consistent development of the application or software product. In HTML/JSP environments, there are no predefined layouts for arranging graphical user interface data entry elements (“widgets”) such as text boxes, combo boxes, checkboxes, etc. Instead, components are arranged within an HTML page using the HTML <table> tag, and such arrangement has to be done manually. This is tedious and time-consuming.
Moreover, since the JSP pages are hand coded for every operation, various pages of the completed application may have an inconsistent look and feel. This problem is compounded when multiple applications interact to form a more complex system, such as an integrated network management product that provides configuration, fault monitoring, reporting, functions, etc. To address the problem with consistent look and feel, some developers follow JSP templates, and use the templates with tools such as Macromedia Dreamweaver. However, this approach does not provide dynamic content generation capabilities and it does not address the problem of having an excessive number of JSP pages.
Thus, typical JSP development involves using custom tags to perform UI related logic. These tags help in hiding the Java® code so that a JSP page looks more like an HTML page that can be constructed using tools such as Dreamweaver. This approach is considered to enhance readability and maintainability of JSP pages; however, the tags are processed by a JSP container object, and are not flexible enough to be manipulated programmatically, and thus are not very suitable for dynamic generation of a UI.
Further, in today's business environment, achieving minimum time-to-market for a software product, software quality, total software maintenance cost and consistency in the look and feel of applications are essential contributors to overall profitability and higher customer satisfaction. Based on the foregoing, there is a need for a mechanism designed to address these problems.
In a variation of the development approach described above, known as MVC or the Model, View, Controller approach, JSP is mainly used for presentation of information, and servlets are used for processing logic. The Apache Struts framework is based on MVC architecture, and also provides a controller servlet that processes HTTP requests from a browser, and invokes appropriate action classes or JSP pages. This approach helps separate processing logic into action classes, thereby making the code more readable and maintainable. Further, the Apache Struts framework provides a set of tag libraries that can be used in developing JSP pages. These tag libraries help in further separating the Java code from JSP pages. However, Apache Struts does not address the issue of the number of JSP pages required by an application for its user interface. Additionally, the Apache Struts approach requires the developer to resolve the task of maintaining a consistent look and feel.
To address the problem of consistency among various company applications, the Enterprise Management Business Unit (EMBU) of Cisco Systems, Inc., San Jose, Calif., has proposed a solution consisting of a set of user interface guidelines and an associated framework. The guidelines, internally known as Picasso, provide a standard for the navigation and for use of various user interface elements. The guidelines help in standardizing the navigation of a GUI, while enabling a developer to determine the specific content of the user interface. As a result, the user interface look and feel is likely to be inconsistent. The framework, termed the UII or User Interface Infrastructure, is based on Apache Struts but follows the Picasso guidelines. The UII framework automates the navigational flow of an application, and provides JSP tags to help develop the content area, but it does not help in reducing the number of JSP pages.
With Picasso, XML documents termed site map XML drive user navigation of application pages. For the content area of an application, Picasso provides tag libraries similar to what Struts already provides, but adds additional tags such as paging table, scrolling table, dialog box, date/time field, etc. However, the developer is required to use the tag libraries in JSP pages created by the developer, and the developer is required to connect the tag libraries with the back end program components using Action classes or Bean classes.
Using Picasso with UII, a developer performs the following steps to create a user interface for an application. First, the developer defines Struts XML files and sitemap XML files. Second, the developer manually creates JSP pages for the content areas of the application. Third, the developer defines a FormBean class, or the equivalent, to hold user interface data for each data entry field. Fourth, the developer creates an Action class for each operation on the HTML page. Fifth, the developer writes business logic to implement each user interface action. A key disadvantage of this approach is that each JSP page for the content areas is created manually.